%\documentclass[draftcls,journal,onecolumn,12pt]{IEEEtran}
\documentclass[9pt,journal]{IEEEtran}
\usepackage{cite}
\ifCLASSINFOpdf
   \usepackage[pdftex]{graphicx}
\else
\fi
%\usepackage[cmex10]{amsmath}
\usepackage{algorithm}
\usepackage{algorithmic}
\usepackage[caption=false,font=footnotesize]{subfig}
\usepackage{url}
\usepackage{color}
\usepackage{booktabs}
\usepackage{bigstrut}
\renewcommand{\baselinestretch}{1.02}
\renewcommand{\algorithmicrequire}{\textbf{Input:}}
\renewcommand{\algorithmicensure}{\textbf{Output:}}
%\addtolength{\textfloatsep}{-5mm}
\graphicspath{{../}}
%\graphicspath{{e:/wese2011/}}

%\title{Teaching Real-Time Embedded Systems using Multiple FPGA Boards}
\title{Project-based Learning in Embedded Systems Education Using FPGA Platform}
\begin{document}
\newcommand{\todo}[1]{\textcolor{red}{[To do: #1]}}

 \author{
\IEEEauthorblockN{Akash Kumar$^{1}$, Shakith Fernando${^2}$ and Rajesh C Panicker${^1}$}
\IEEEauthorblockA{\\$^1$Department of Electrical \& Computer Engineering, National University of Singapore, Singapore\\
$^2$Department of Electrical Engineering, Eindhoven University of Technology, The Netherlands\\
Corresponding author email: akash@nus.edu.sg}
}
\maketitle

\begin{abstract}
%\todo{Touch-up!}
With embedded systems becoming ubiquitous, there is a growing need to teach and train engineers who are well-versed in designing and developing such systems. Owing to its multi-disciplinary nature, imparting exposure and experience in all facets of such systems is challenging. In this paper, we describe two projects that are being used at the National University of Singapore for two courses -- one on real-time embedded systems and the other emphasizing the hardware aspects of embedded systems. These projects use field programmable gate arrays (FPGAs) to impart hands-on learning to students. A generic architecture is used that allows various types of projects to be built upon it.%This allows students to experiment with and appreciate the various tradeoffs while designing embedded systems.

The goal of real-time embedded systems project is to develop a five-a-side soccer system on multiple FPGA boards using embedded processors. %Besides exposing students to real-time concepts like scheduling, handling shared resources and priority management, the project also makes them appreciate the constraints in a typical embedded system while still making it a fun experience for them. A mini-competition is organized at the end of the project where all teams compete against each other in a tournament with 5-minute games where the progress of the game is shown on the VGA screen. 
In the embedded hardware design project, students use an embedded processor based system to perform decryption of a block encrypted image, accelerated through a custom co-processor. %Multiple hardware/software designs are implemented to evaluate the cost-performance trade-offs. The encrypted and decrypted image are displayed on an attached VGA screen. 
The approach adopted in the projects gives students a sense of accomplishment while reinforcing the theoretical concepts. The use of displays gives students a visual/interactive experience. Both projects have run successfully for two terms and were well appreciated by students.

\end{abstract}
\begin{keywords}
FPGA; embedded systems education; hardware-software co-design; real-time; project-based learning.
\end{keywords}


\section{Introduction}
\label{sec:Introduction}

Modern embedded computing platforms are fast becoming more heterogeneous and therefore more complex to design and program. Multi-core based mobile phones (e.g. Tegra) and hybrid platform with both hard multi-core processors and reconfigurable area (e.g. Xilinx Zynq) are examples of such systems in the consumer electronics domain. The market for embedded systems is ever increasing with the consumer electronics domain expected to expand by 41\% in volume while the rest of domains are not far behind with a forecast of 35\% in automotive and 37\% in telecommunications. This means the current 16 billion devices (roughly three embedded devices for every living person) is expected to grow to 40 billion by 2020~\cite{artemis}. Driven by shorter time-to-market demands, Commercially available Off-The-Shelf (COTS) components are used more and more in the hope of reducing overall system development time and costs \cite{cots3}. Using COTS components can often increase sytem-integration work and dependency on third-party vendors. Hence, a good embedded curriculum should not only teach and train engineers to design such complex and heterogeneous embedded computing systems, but also teach them industrially relevant design challenges in using COTS components.%\todo{is it clear?} %(http://www02.abb.com/global/gad/gad02077.nsf/lupLongContent/CA2E87697F209701C12571920029ED7B)

%Today's embedded computing platforms are fast becoming more diverse and more complex. Multi-core based mobile phones (e.g. Tegra) and hybrid net-books with FPGAs (e.g. Intel E600C) are two examples of such systems in the consumer electronics domain. Driven by Moore's law and ever reducing costs, embedded computing has further expanded from traditional application domains such as avionics and automotive industries to consumer electronics markets. This rapid proliferation is predicted to rise to 24.6 billion multi-processor based embedded systems by the year 2020~\cite{IDC}. Therefore, teaching and training engineers to design such complex and diverse embedded computing systems has become very important.

Teaching {\em embedded systems} as an integrated topic is a difficult task since it can be very diverse and multidisciplinary~\cite{1266754,Koopman:2005:UES:1086519.1086522,grimheden2005embedded,Muppala:2007:BES:1217809.1217812}. It can range from micro-controller basics and real-time concepts to hardware/software co-design, distributed processing, reconfigurable computing and system-level architecture design~\cite{jackson2005embedded}. Designing a project spanning multiple learning objectives which students can relate to is important to motivate them to acquire the skills for designing embedded systems. Further, these projects must simulate industrial relevance by including component-integration with COTS components while balancing the learning curve required for them within the time-span of the course.
%It is important to understand the balance between the various facets in order to build high-performance embedded systems.
%The ability to understand and debug with limited documentation is %subtle,
%difficult to convey and teach using traditional methods~\cite{Edwards:2005:ETF:1121812.1121823_WESE}.

%\begin{figure}[!t]
%\centering
%%\includegraphics[width=3.5in]{project_setup.pdf}
%\includegraphics[width=0.95\columnwidth]{images/spartan_board.jpg}
%\caption{Spartan 3E Board from Digilent~\cite{digilent}}
%\label{fig:board}
%\end{figure}

In this paper, we describe our teaching methodology and experiences at National University of Singapore (NUS) in teaching two embedded systems courses. This paper extends the previous published work on the real-time embedded course (EE4214)~\cite{Kumar:2011:BSF:2077370.2077377}. This paper describes application and evaluation of this teaching methodology to another course -- the embedded hardware systems design (EE4218). We also propose a generic architecture for design projects using COTS hardware and IP with lab assignments to reduce the learning curve of students in using them. Students receive 4 modular credits for each course which translates to approximately 130 hours of work over one semester spanning over four months. The modules are offered as electives for final year undergraduate students. The courses are attended by about 80 students each year. They are expected to be familiar with the basics of computer architecture and are expected to be comfortable with C/C++ and VHDL (for EE4218). Concepts are taught through a series of lectures, tutorials, lab exercises and a project. The labs and project form a very important part of the module determining 50\% (EE4214) or 60\% (EE4218) of the final grade for the students. The labs are aimed to help students appreciate the theory that is taught in the lectures and to gain the required knowledge and experience for the project.

The real-time embedded course includes a major design project that is carried out on a state-of-the-art COTS hardware (Xilinx Spartan 3E board from Digilent~\cite{digilent}). The aim of the project is to design a system for 5-a-side soccer. The system comprises of 1) a client strategy controller and 2) a server to referee and display the game in real-time. At the end of the semester, all teams compete against each other to determine the winner. The competition element motivates the students and brings out the best in them.

The aim of the embedded hardware design project is to design a hardware accelerator for compute-intensive tasks of two encryption algorithms -- Advanced Encryption Standard (AES) and PRESENT~\cite{daemen2002aes,bogdanov2007present}. The students are also required to explore the design space of these accelerators and analyze the performance and area trade-offs. The encoded and decoded images are displayed on a monitor to give a visual and interactive experience.

Our distinguishing features of both projects are as follows:
%\todo{Still needs some work.}
\begin{itemize}
  \item They have a good balance of breadth (real-time concepts, multi-processor architectures and FPGA exposure) and depth (theory and implementation of real-time and hardware design concepts).
  \item They give an opportunity for students to get hands-on experience in using real hardware.
%  \item It has a good balance of theory and practical knowledge as there are assignments to teach various real-time embedded system concepts keeping the project in mind.
  \item Lab assignments on the generic architecture are provided to reduce learning curve of the students in mastering the complicated tool-chain as well as other aspects necessary for the projects.
  \item They expose students to the analysis of the design space trade-offs given hardware area constraints in real industrial COTS hardware.
  \item They provide a visual and interactive design experience.
  \item They have a fun and competitive element to motivate students and enhance learning experience.
  \item They encourage students to share ideas, work in teams and manage time and resources effectively.
\end{itemize}

Furthermore, weekly consultations are arranged with the teaching assistants to encourage student discussions on projects from the first week itself. This not only helps them with the problems related to the tools and hardware, but also helps ensure that they are on the right track to complete the projects within the stipulated time. For project management and dissemination of information, two wiki pages are setup~\cite{wiki4214,wiki4218}. This is very useful to share resources such as data-sheets, detailed project specifications and updates at one place. The wiki page also allows students to share the know-how in solving technical problems related to hardware and EDA tools.
%FAQ page and discussion forum became very lively as it enabled the students to share

%\todo{Still needs some work.}
This paper is organized as follows. Section \ref{sec:RelatedWork} summarizes the related work on embedded systems education. Section \ref{sec:GenericArchitecture} gives a brief overview of the generic embedded architecture used for both courses at NUS. Section \ref{sec:RealTimeEmbeddedSystems} and Section \ref{sec:EmbeddedHardwareSystemsDesign} describe the projects as well as the lab assignments given to students for real-time embedded and embedded hardware design courses respectively. Section \ref{sec:ProjectEvaluation} describes the evaluation criteria while highlighting some projects with innovative ideas. Feedback obtained from students is also summarized therein. Section \ref{sec:ConclusionsDiscussions} concludes the paper with a discussion on the insights gained from these projects.

\section{Related Work}
\label{sec:RelatedWork}
%\todo{Add about embedded curriculum ideas.}

One of the earliest papers to propose a multidisciplinary approach for analysis and design of complete embedded systems was by Wayne Wolf {\em et al.}~\cite{wolf2000embedded}. Until then teaching in this area was largely ignored by academics because it had not thrown up sufficient challenges~\cite{lee2000s}. There has been a growing interest in discussing various teaching methodologies for embedded systems education recently, as shown by the number of papers published in IEEE transactions on education in this area~\cite{1266754,5951809,4472099,1356101, 1427878}. Further, publications targeting only embedded systems education such as Special Issues on Embedded Systems Education in ACM Transactions on Embedded Computing Systems~\cite{Koopman:2005:UES:1086519.1086522,grimheden2005embedded} and Workshop on Embedded Systems Education (WESE)~\cite{Muppala:2007:BES:1217809.1217812,jackson2005embedded,Edwards:2005:ETF:1121812.1121823,Hansson2009} have been initiated to address the challenges in this area. The industry has also been organizing embedded design competitions for students involving a fun and competitive element to promote embedded computing e.g. embedded design track at Microsoft Imagine Cup~\cite{mic}, Intel Undergraduate Embedded Design Contest~\cite{nuedc} and Xilinx OpenHW Contest~\cite{xilinxopenhw}.

%Until early 2000s, teaching in this area was largely ignored by academics because it had not thrown up sufficient complex research challenges as pointed out by Lee~\cite{lee2000s}. Wayne Wolf et al~\cite{wolf2000embedded} were one of the first to propose a multidisciplinary approach to analysis and design of complete embedded systems. Since then, there has been a significant interest in the academic community towards formal teaching methods for embedded education as shown by the papers published in Special Issues on Embedded Systems Education in ACM Transactions on Embedded Computing Systems~\cite{Koopman:2005:UES:1086519.1086522,grimheden2005embedded} as well as the papers in the Workshop on Embedded Systems Education (WESE)~\cite{Muppala:2007:BES:1217809.1217812,jackson2005embedded,Edwards:2005:ETF:1121812.1121823,Hansson2009}. The industry has also shown interest by organizing student embedded design competitions which involve a fun and competitive element to teach embedded computing e.g. embedded design track at Microsoft Imagine Cup~\cite{mic} and Intel Undergraduate Embedded Design Contest~\cite{nuedc}.

%\todo{Grouping}
%We look at design projects for teaching real-time systems and those with multi-processor systems. As the use of FPGA as a teaching tool is extremely popular, we limit our discussion on FPGA based projects to the ones with a combination of real-time system and/or multi-processor systems. Table \ref{tab:rw} compares different features of various design projects used for teaching.

We compare the design projects used to teach real-time embedded systems followed by those for embedded hardware design. For real-time embedded systems, we look at what kind of problems various design projects try to solve and their real-time constraints. We also look at whether a project incorporates a uniprocessor or a multi-processor system, and whether FPGA is used as a teaching tool. The features of various design projects are summarized in Table \ref{tab:rw} and explained below.

% Table generated by Excel2LaTeX from sheet 'Sheet1'
\begin{table}[t]
\setlength{\tabcolsep}{4pt}
  \centering
  \caption{Comparison of features in design projects to teach embedded systems}
    \begin{tabular}{|p{2.5cm}|p{2.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|}
    \hline
     & Contains a real life problem with real-time  constraints? & Embed-ded Hardware & Use of Multi-processor & Use of FPGA as a teaching tool \bigstrut\\
    \hline
    McCormick {\em et al.}~\cite{mccormick2005we} & Yes  & No  & NA  & NA \bigstrut[t]\\
    Mehdi {\em et al.}~\cite{Amirijoo:2004:RMR:971300.971394} & Yes & No & NA  & NA \\
    Hansson {\em et al.}~\cite{Hansson2009} & Maybe & Yes & Yes & Yes \\
    Ttofis {\em et al.}~\cite{5951809} & No & Yes & Yes & Yes \\
    Edwards {\em et al.}~\cite{Edwards:2005:ETF:1121812.1121823} & Dependent on the proposal  & Yes & NA  & Yes \\
    Previous NUS~\cite{oldee4214} & Dependent on the proposal & Yes & No  & No \bigstrut[b]\\
    \hline
    Our design project & Yes & Yes & Yes & Yes \bigstrut\\
    \hline
    \end{tabular}%
  \label{tab:rw}%
\end{table}%

%\todo{For Shakith to double check PC part.}
%\todo{rephrase to avoid same pattern for all paras}
A railroad control system as a real-time project is described by McCormick {\em et al.}~\cite{mccormick2005we}. This is a very good example of a problem with real-time constraints. The use of model trains provides a fun aspect for students. %However, as most of the control systems are implemented using PCs, the student may not get a chance of the experience in developing embedded software under constraints (e.g. memory limitations).
Mehdi {\em et al.}~\cite{Amirijoo:2004:RMR:971300.971394} also propose a soccer system. However, their game play is run on a PC, while our project requires students to implement the system on a real embedded platform. Neither project focuses on the usage of multi-processors or FPGAs. Hansson {\em et al.}~\cite{Hansson2009} propose a design project where students partition and map JPEG decoder on to a multi-processor platform running on an FPGA. It emphasizes on the diverse aspects of designing embedded systems with multi-processors, FPGA and Network-on-Chip communications. However, their focus is more on hardware/software co-design and the underlying architecture is static. In contrast, our project allows students to generate their custom hardware design.

Edwards {\em et al.}~\cite{Edwards:2005:ETF:1121812.1121823} share their teaching experience on embedded systems using FPGA as a teaching platform. This is a practical course where students are allowed to define their own project and implement it on hardware. Although the course does not necessarily require real-time systems, quite a few of the projects have real-time requirements (e.g. real-time video effects processor). Another similar project is proposed by Ttofis {\em et al.}~\cite{5951809} using a multi-processor based Network-on-Chip platform. They propose an FPGA-based teaching framework on this platform using several benchmark applications. While this also encompasses various aspects of designing embedded systems with multi-processor, FPGA and Network-on-Chip communications, our projects simulate more industry-relevant scenarios by targeting a real application with real-time requirements.
%Multi-processor systems are not a requirement for this teaching project.

For the previous real-time embedded systems design project at the National University of Singapore (NUS)~\cite{oldee4214}, students defined a real-time application and implemented it on an embedded platform. The platform provided was a Motorola uCSimm module with a MC68EZ328 Integrated Processor and RTAI uClinux operating system. Due to the complexity of the platform and limited documentation, the students spent considerable amount of project time debugging Linux and hardware issues instead of learning and implementing real-time concepts. In our design project, we use a real-time soccer controller system as the application. This is a good example of a problem with real-time constraints to be met. Our hardware consists of multiple FPGA development boards, each configured as a multi-processor system-on-chip.

The related work on design projects of embedded hardware design with a hardware accelerator as a co-processor is quite limited. Schaumont {\em et al.} propose a hardware-software co-design course to explore design space of hardware accelerators for encryption. However, all custom hardware and software trade-offs are only simulated, whereas in our project the accelerators are implemented on real hardware in~\cite{4472099}. Mitsui {\em et al.}~\cite{4914744} propose a design project for DCT co-processor for JPEG application on an Altera NIOS2 development kit. The students are also expected to explore design space of the hardware accelerator for DCT. This is quite similar to our design project, but our target is to the design the whole system for the complete application together with the co-processor design for encryption.
% and our target platform is a Xilinx FPGA with Microblaze processor as the master processor.\todo{We have overall system rather than only a component.}

Hall {\em et al.}~\cite{1356101} describe a design project using system-on-a-programmable-chip for their student project. The students are expected to implement an application (e.g. remote controlled vehicle, robot control) of their choice on system-on-a-programmable-chip consisting of a soft processor and custom hardware logic. A similar System-on-Chip project is described by Bindal {\em et al.}~\cite{1427878}, where a servo controller for a robotic arm is implemented on Excalibur chip with an embedded ARM processor and programmable logic. In our design project, the computational intensive components of two encryption algorithms are implemented as a co-processor to the main processor. Students are expected to explore multiple design space points (one software and several hardware implementations) and compare their trade-offs. They must also implement this on real hardware and show the encoded and decoded images on the VGA display. This allows for a visually stimulating and interactive learning experience for the students.

%We focus on implementing several real-time concepts using the lab assignments and the project. This project also exposes the students to the need of teamwork, time management and efficient communication as in a multi-dimensional industry project.

\section{Generic Hardware Architecture}
\label{sec:GenericArchitecture}
%\todo{Talk about the generic architecture, add how such a platform can be used for different types of embedded projects. In the following two sections, give examples.}

\begin{figure*}[!t]
\centering
%%\includegraphics[width=3.5in]{project_setup.pdf}
\includegraphics[width=0.7\textwidth]{images/generic_architecture.pdf}
\caption{Block diagram of the generic architecture for embedded systems projects}
\label{fig:generic_architecture}
\end{figure*}

The projects are carried out on a Xilinx Spartan-3E FPGA board from Digilent~\cite{digilent}. The board features a Xilinx Spartan-3 1600 FPGA with about 1.6 million gates that can be reprogrammed. It also offers a number of Input/Output options to interface with other peripherals. Some of the relevant I/O ports are two serial terminals and a VGA port. The serial port is used in the projects to communicate with other FPGA boards and/or PCs while the VGA port is used to show output on an external screen.

The generic architecture of FPGA configuration is shown in Figure~\ref{fig:generic_architecture}. The architecture consists of two Microblazes -- a soft-processor from Xilinx -- connected via PLB (Processor Local Bus). Using Microblaze allows them to define system behaviour using C/C++ language. Further, various enhancements to processor architecture can be made through the Xilinx EDK/XPS (Embedded Development Kit/Xilinx Platform Studio) tool-suite e.g. hardware multiplier and floating-point-unit. The EDK/XPS environment also allows easy customization of the system by adding/configuring various hardware IPs (Intellectual Property) provided in the toolkit.

For the projects in the two modules, some of the relevant IPs besides Microblazes that are instantiated are listed below.
\begin{itemize}
\item {\bf PLB:} This bus allows various peripherals to be instantiated and connected to it as slaves. Microblazes, as masters, are able to communicate with these peripherals arbitrated by PLB.
\item {\bf Timer:} This IP allows Microblazes to keep track of time elapsed while executing various software/hardware routines. Further, it is useful as a system-timer for operating system kernels.
\item {\bf VGA controller:} This controller renders video frames to the VGA port from a video buffer. The on-board hardware supports maximum resolution of up to 640x480 pixels with 3-bit color depth at 25Hz. This is taken into account while designing the project specifications.
\item {\bf DDR SDRAM controller:} The memory forms a very important part of the system and the controller is used to arbitrate access to the DDR memory. The memory is used for storing the video buffer, program code for processors and serves as data memory.
\item {\bf UART controller:} Serial ports are useful for both inter-board and PC-board communication.
\item {\bf Co-processor:} The use of custom co-processor allows hardware acceleration of some of the compute-intensive parts of software.
\item {\bf Mutex and Mailbox:} These are used for data communication between the Microblazes.
\item {\bf Interrupt controller:} This module is used to interrupt the processor to ensure real-time behavior of the software.
\end{itemize}
%In the case of EE4214, the progress of the game is shown, while in EE4218 project the encoded/decoded image is displayed.
The generic architecture used in the labs allows a variety of projects to be developed that expose students to various issues in embedded and real-time systems, while still stimulating the students with immediate visual output of their hard work. This platform allows both pure software and hardware-accelerated projects to be developed.

\section{EE4214 Real-Time Embedded Systems}
\label{sec:RealTimeEmbeddedSystems}
{\em EE4214} starts with giving an overview of the importance of making embedded systems real-time. The concepts of real-time systems like scheduling and handling shared resources are introduced. This is followed by an overview of design methodology for real-time software. Other in-depth technical topics such as concurrent programming, deadlock management, synchronization mechanisms, as well as other aspects of an embedded computer system which affect real-time performance are discussed. At the end of the module, they are expected to:
\begin{itemize}
	\item be familiar with design methodologies for real-time embedded systems,
	\item understand the importance of analyzing timing behavior in embedded systems,
	\item understand the many factors affecting real-time performance in embedded systems, and
	\item apply these concepts to design embedded systems with real-time performance.
\end{itemize}

%\section{Project Overview}
%\label{sec:ProjectOverview}

The project is inspired by the Soccer World Cup. The objective of the project is to develop a 5-a-side soccer system using multiple FPGA boards. The project is carried out in groups of up to 6 students. The groups have to design the hardware architecture of the embedded system and the software for the strategy to control how to move the players in response to the position of all players and the ball. They also develop a server to communicate with the two teams and display the progress of the game on an attached VGA monitor.

\subsection{EE4214 Lab Foundation}
\label{sec:ProjectFoundation}

%\todo{adapt the figure to include co-processor as well and show different highlighting for different modules. Add a screen to the VGA controller.}
% Table generated by Excel2LaTeX from sheet 'Sheet1'
\begin{table}[t]
  \centering
  \caption{List of Lab Assignments}
    \begin{tabular}{|c|p{2.5cm}|p{4.5cm}|}
    \hline
    Lab & Topic & Relation to Project \bigstrut\\
    \hline
    1   & Familiarization with FPGA and EDK & Using VGA screen for the soccer game display. \bigstrut\\
    \hline
    2   & Threads & Using different scheduling algorithms to control player tasks. \bigstrut\\
    \hline
    3   & Software and Hardware Mutexes & Using shared resources like the serial communication channel between two boards in the project setup. \bigstrut\\
    \hline
    4   & Message Queues and Mailboxes & Learning inter-process communication to pass data between threads within a core and between two cores. \bigstrut\\
    \hline
    5   & Binary and Counting Semaphores & Controlling the number of active player threads on the soccer field. \bigstrut\\
    \hline
    6   & Priority Inheritance Protocol/ Priority Ceiling Protocol & Implementation of dynamic priority for cases when the priority of a thread may need to be increased to limit the blocking time of higher priority threads. \bigstrut\\
    \hline
    \end{tabular}%
  \label{tab:labassignments}%
\end{table}%

Each lab consists of two parts: 1) the first part consists of a tutorial where step-by-step guidance is given to implement real-time concepts on multi-processor systems, 2) the second part is an assignment to allow students to use practical knowledge gained from the first part to solve a fairly simple design and implementation problem. A total of six lab assignments are provided to students as shown in Table~\ref{tab:labassignments}.
Lab-1 introduces students to Xilinx tools by implementing a Microblaze-based system on a Spartan-3E board. %In this lab, they learn how to implement a single-processor system along with associated peripherals such as UART and DDR memory. They also learn to interface a VGA controller and draw a moving object on the attached screen.
In the second lab, students learn to implement a dual-processor system with additional hardware such as mutexes and mailboxes as shown in Figure~\ref{fig:generic_architecture}. %This complete hardware setup is designed such that the same hardware design can be used for the remaining labs. %This helps reduce development time and debugging unnecessary tool issues and help  students focus on real-time embedded software development.
Students also learn usage of real-time OS called {\em xilkernel} and implement round-robin and priority-based schedulers with multiple threads.
Lab-3 allows students to experiment with both hardware and software mutexes and appreciate their relevance. %The assignment involves using the dual-core system to use the shared UART resource effectively between threads in the same core and in different cores.
In Lab-4 and Lab-5, students learn to implement inter-process communication and semaphores respectively. %They learn to use message queues for passing messages between threads on the same processor core and use mailboxes for passing messages between threads on different processor cores. They also learn to implement binary and counting semaphores and explore their usefulness in the real-time context of the soccer game.
In Lab-6, students implement solutions to problems caused by priority inversion. %When a low priority thread has locked a certain resource which is required by a high priority thread, the high priority thread may get blocked for an unbounded period of time in presence of medium priority threads. In this lab, they learn to bound this blocking time using Priority Inheritance and Priority Ceiling Protocols.

%Additionally, a guest lecturer (Assoc. Prof. Prahlad Vadakkepat), an expert on robot-soccer strategy is invited to give students a flavour of how an actual robot-soccer player system is designed. The foundation he gives on SimuroSot~\cite{simurosot} (Robot-Soccer Simulation on PC) provides students the inspiration to explore their own strategies for controlling their players.


\subsection{EE4214 Project Details}
\label{sec:ProjectDetails}
\begin{figure}[t]
\centering
%%\includegraphics[width=3.5in]{project_setup.pdf}
\includegraphics[width=3.5in]{images/project_setup.pdf}
\caption{The setup with multiple FPGA boards for the soccer project}
\label{fig:project_setup}
\end{figure}

The project is set up as shown in Figure \ref{fig:project_setup}. As can be seen, the entire setup requires three FPGA boards -- one for the server which also referees the game and two to run heuristics from each team. The teams send updates of player movements to the server periodically. The server board processes the updates from both teams and displays the players and the ball on the attached VGA screen. Positions of the ball and players of both teams are sent back to them. Many constraints have been added to simulate real-life scenarios, e.g.\ how fast the players are allowed to run and the maximum speed of the ball. These need to be respected in the design of students. %Major tasks of client and server are shown in Figure~\ref{fig:project_setup}.

Figure~\ref{fig:project_setup} also shows the tasks that are to be carried out by clients and the server. One of the main tasks is to send the player movement information to the server from the client. It is important to note that the client does not send actual positions of the players during the game, as this may result in some unrealistic movements, e.g. the client may move a player from the center of the field to near the goal instantly. The client, therefore, only sends the direction towards which the player intends to move and the speed at which the movement is desired. The server on the other hand, sends the absolute positions of the players back to the teams. The speed and direction of players is not sent by the server since that may reveal the strategy of the other team. The server only sends the information that is generally available to the other team in a real game. Another major task of the server is to simulate the physics of the game. The physical laws e.g. the conservation of momentum, have to be respected by the server when a collision occurs. When {\em kick} information is received by the server, it evaluates the distance between the ball and the player, and only executes the kick if the two are sufficiently close. The server also referees the game. A number of rules have to be followed for fair play. While it is not feasible to implement all of them in a virtual world with limited resources, some of them can be easily implemented, e.g.\ off-side. %Figure~\ref{fig:field} shows the layout of the planned field to be displayed by the server. We attempted to make the relative sizes of the field, players and the ball as realistic as possible. Some space is reserved for displaying score and foul information.%It is interesting to note that the corners have been {\em cut-off} from the field to avoid situations when the ball may get stuck at corners.


%\begin{figure}[t]
%\centering
%%%\includegraphics[width=3.5in]{project_setup.pdf}
%\includegraphics[width=3.5in]{images/field.pdf}
%\caption{Layout of the soccer field (not to scale).}
%\label{fig:field}
%\end{figure}


%Needless to say, that the aim of the game is to score as many goals as possible during the duration of the game. In the event that the score is equal, the winner is decided by counting the number of fouls that are committed.

The hardware setup with multiple FPGA boards allows students to explore issues that are typical in any real-time embedded system. Further, the project has a number of issues that require real-time behaviour and presents opportunities for exploring many concepts that are taught in theory. For example, the screen refresh rate is specified as 25 Hz. This implies that all computation of physics on the server and data communication, among other tasks, need to be completed within 40ms. The serial communication baud-rate is fixed at 115,200 bps; this together with the limited buffer of 16 bytes imposes strict constraints to ensure no packets are lost. The amount of memory available on the FPGA is also limited, implying that the program code cannot be very long. When students use external DDR memory, they have to be careful about resource sharing. The memory may be shared between various processors running on the same FPGA board and also the VGA controller in the case of the server. Such scenarios force students to think of many related issues in the design of a typical real-time embedded system. %Figure~\ref{fig:block_diagram} shows the architecture of the dual-Microblaze design that most students use for the server.

Since each team individually develops their client and server designs, it is important to have a well-specified communication protocol to ensure that they can seamlessly communicate with the other teams. Such a well-defined protocol allows {\em plug-n-play} behaviour where we can take clients from any two teams and the server from a third one. 
%A brief overview of the communication protocol is provided below.
%
%\subsection*{Player to Server Communication}
%\noindent Two kinds of data packets are sent from player boards to the server board. At the start of a game, player boards send packets that specify the team-id, player-ids, and the initial coordinates of all players to the server. Four bits are allocated for the player-id so that more players can be accommodated in the future versions of the project. The server does not start the game until it has received the details of players from both teams. Once the game has started, the player boards send update packets to the server board, indicating the speed and direction of individual players of their team. Players can either move or kick the ball in any of the 16 predefined directions as shown in Figure~\ref{fig:field}. The speed of a player can have 11 values representing a range of speed from 0 to 50 pixels per second, while the speed range of the ball is larger with 16 values ranging from 0 to 100 pixels per second.
%
%\subsection*{Server to Player communication}
%\noindent The server board sends two kinds of packets to the player boards -- update and control packets. The update packets to each board contain information about the current position of players as well as of the ball. In case of a foul or a goal, the server transmits a control packet that indicates the type of event and the team responsible for the event.
%
%The communication between the boards takes place through the two standard RS-232 ports available on the Spartan-3E boards. The baudrate is fixed at 115200 bps so as to avoid any performance issues due to communication bottleneck.

%\todo{The part below overlaps with earlier part. Need to see where it is more appropriate.}
%The refresh rate of 25 Hz puts a time constraint on the server of 40ms for calculating the position of ten players and the ball before updating the video frame with the new values. Additionally, the transmission of the player and positions to the client boards also had to be performed within this time constraint, thereby putting a tremendous load on the server board.

\section{EE4218 Embedded Hardware Systems Design}
\label{sec:EmbeddedHardwareSystemsDesign}
{\em EE4218} module starts with a description of general embedded systems design methodology. Various implementation technologies (e.g. ASIC, FPGA) are introduced and their trade-offs are discussed. Students then learn the internal FPGA routing and details of its logic elements. The module also discusses the strategies for area and latency optimization, as well as designing finite state machines. The different steps involved in converting the RTL description to implementation are also covered. They learn about algorithms required for logic minimization, technology mapping and physical synthesis. Special emphasis is laid on FPGA architecture. A revision to a hardware description language (VHDL, to be specific) covered in a first-year module is also done. At the end of the module, they are expected to:
\begin{itemize}
	\item be familiar with design methodologies for embedded systems,
	\item be able to translate system specifications into a register-transfer level HDL that can be implemented on an FPGA,
	\item understand the performance-resources trade-offs while designing embedded systems, and
	\item appreciate the back-end algorithms that are used in electronic design automation.
\end{itemize}

%\subsection{Project Overview}
%\todo{Add a figure about the project similar to the one in Project slides like EE4214 figure.}
The aim of the project in EE4218 module is to enable the students to appreciate the various steps involved in designing an embedded system using state-of-the-art commercial tools. In this project, students (in groups of two) are required to implement an algorithm in both software and hardware and measure speed-up, if any. Since the module assumes that students have only a basic understanding of digital circuits, a series of labs is designed to help them familiarize with FPGA-based embedded systems development using soft-processors and hardware IPs (Intellectual Property).

\subsection{EE4218 Lab Foundation}
Table~\ref{tab:ee4218labassignments} shows the list of lab assignments that students undergo as a part of preparation for the main project. In the first lab, students familiarize themselves with Xilinx ISE tool-chain and Spartan-3E development board. They develop some simple combinational and sequential modules in VHDL and demonstrate the functionality on the FPGA board. The second lab introduces the students to embedded systems development. They learn how to design a processor-based system using Microblaze. This allows them to define system behaviour using C-language. The EDK/XPS (Embedded Development Kit/Xilinx Platform Studio) environment allows easy customization of the system by adding/configuring various hardware IPs and the processor provided in the toolkit. In the last lab, students learn how to design and add custom modules to the platform. These labs provide sufficient background knowledge for designing complete embedded system with hardware accelerators, thereby enabling hardware/software co-design and studying the associated trade-offs amongst various alternatives.

% Table generated by Excel2LaTeX from sheet 'Sheet1'
\begin{table}[t]
	\setlength{\columnsep}{1pt}
  \centering
  \caption{List of Lab Assignments for EE4218}
    \begin{tabular}{|c|p{3.7cm}|p{3.7cm}|}
    % \begin{tabular}{|c|l|l|}
    \hline
    Lab & Topic & Relation to Project \bigstrut\\
    \hline
    1 & Familiarization with ISE and revision of VHDL & Design modules in hardware \bigstrut\\
    \hline
    2 & Developing embedded systems using EDK/XPS & Write software description of modules \bigstrut\\
    \hline
    3 & Designing and adding custom peripherals & Designing co-processor and communicating with Microblaze \bigstrut\\
    \hline
    \end{tabular}%
  \label{tab:ee4218labassignments}%
\end{table}%

\subsection{EE4218 Project Details}
\begin{figure}[!t]
\centering
\includegraphics[width=1\columnwidth]{images/ee4218-project-setup.pdf}
\caption{Setup for EE4218 project}
\label{fig:ee4218-project-setup}
\end{figure}
One of the major aims of the project is to emphasize on the importance of hardware acceleration for compute-intensive tasks.
Figure \ref{fig:ee4218-project-setup} shows an overview of the project setup. As shown in the figure, a screen is attached to the FPGA board. The encoded image and the key used for encryption are sent over the serial port from the computer to the FPGA board. The decryption is carried out on the FPGA and the encoded and decoded images are displayed on the attached screen. Since the supported screen-size is 640x480 pixels, the image size is set to 320x240 pixels for convenient display of images. Since the VGA port on Spartan-3E FPGA board only supports 3-bit colours, a custom image format is defined to pack multiple pixels into bytes. A desktop application is written to convert an image in commonly-used formats to the required format. The application crops input images to the desired size and packs every five pixels into two bytes ($3\times 5+1=16$). A random bit is generated and stuffed at the end. The addition of a random bit adds noise, making the encryption stronger and removes any visible data-dependent patterns in the image.

%Figure~\ref{fig:co-processor-flow} shows the flow of hardware-software design of the project. 
Most of the parts are run on the Microblaze with a hardware module for image decryption. A dummy module is provided to students for the hardware co-processor connected to the MB with FSL ports. While one software implementation is sufficient, at least a couple of hardware alternatives are expected. This offers sufficient opportunities to explore various hardware architectures and study the trade-offs in area and latency, over and above the hardware vs.\ software considerations. At the end of the project, they are expected to show the results in a Pareto curve depicting various architectures designed and evaluating them in terms of LUTs required and the latency of the design.

In the last two years of running this project, Advanced Encryption Standard (AES) (128-bit data and key) and PRESENT (64-bit data and 80-bit key) were chosen for the implementation~\cite{daemen2002aes,bogdanov2007present}. The general framework allows for selecting a different algorithm each year in order to minimize plagiarism with minimal changes to the project.

%\begin{figure}[!t]
%\centering
%\includegraphics[width=1\columnwidth]{images/co-processor-flow.pdf}
%\caption{EE4218 co-processor flow}
%\label{fig:co-processor-flow}
%\end{figure}
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=1\columnwidth]{images/Pareto.pdf}
%\caption{Resource - Timing Pareto curve}
%\label{fig:ee4218-pareto}
%\end{figure}

\section{Project Evaluation}
\label{sec:ProjectEvaluation}
Labs/projects determine significant portion of the grades for the embedded systems courses described here. At the end of the semester, all teams have to give a presentation describing their system design, key distinguishing features and work-division among the team members. The students have to justify the design choices they make in the projects and appreciate their importance. A short demonstration is also expected to showcase the basic functionality and extra features in the design.
%
\subsection*{EE4214 Example Projects}
\label{sec:ExampleProjects}
\noindent A few of the innovative features and ideas that the students have come up with during the implementation of the project are mentioned in this section. While implementing the server, only a few teams were able to meet the constraint of refreshing the screen at the required refresh rate of 25 Hz, even after allocating a separate core exclusively to deal with the screen refresh task. This issue was due to the contention between the Microblaze and the VGA controller while accessing the video frame buffer. A part of the off-chip DDR2 memory was allocated to the VGA controller as video frame buffer. A very innovative idea was presented by one of the teams to overcome this issue. The solution adopted by the team was to have two separate video frame buffers, one for each alternate video frame. Their code swapped the pointers to the video frame buffers every alternate refresh cycle. They were able to easily achieve the required refresh rate using this approach.

Another attractive feature that was integrated by one of the teams was that of a replay system. The positions of all the players and the ball were stored in the memory for the entire history of the game and then replayed when triggered by on-board push-buttons. The team also allowed the game to be paused using a push-button. Yet another interesting feature was to allow changing run-time strategy depending on the progress of the game. A video clip of a match conducted in the tournament is available at~\cite{wiki4214}. The tournament provides an excellent platform for the groups to test the quality, robustness and interfaceability of their design.


%Quite a bit was repeated..
%After the evaluation of individual groups, a mini soccer tournament is organized between all the groups to introduce the element of fun and competition. Client boards compete against each other, using a common server for the whole tournament. The best server design which is able to achieve smooth 25Hz refresh rate is chosen. The winner of a match is decided by the number of goals each team scores or by the number of fouls each team commits in case of a tie.

%\todo{Adapt the example projects section to include expandability of the projects by students themselves.}

\subsection*{EE4218 Example Projects}
\label{sec:EE4218ExampleProjects}
During the presentations, a whole spectrum of hardware architectures is seen in the student projects. Some groups have fully pipelined design capable of decrypting one block of data per clock cycle. Some others decided to use multiple decryptor modules to speed up image decryption. Few students explored hardware/software co-design by accelerating only specific functions in hardware, thereby providing good performance-resource trade-offs.

An example of an extra feature implemented by some groups in EE4218 project was to send encrypted images via Ethernet port using lwIP (light-weight Internet Protocol) instead of serial port. Ethernet port allowed them to send images at a much faster rate than serial port. Some of the groups went further and used this feature to decrypt video on the fly. Video data was decoded on a PC into individual frames; these frames were then encrypted on the PC and sent to the FPGA board for decrypting. Essentially this was similar to Motion JPEG encoding, except that individual frames were encoded in our custom format. A couple of groups also extended the design to use HDMI interface (using Atlys Spartan-6 board~\cite{digilent}) for displaying the video instead of VGA, thus allowing higher screen and colour resolution. Many groups also implemented both encryption and decryption where the choice could be made via an on-board dip-switch. A video clip showing some of the features from a project can be seen online at~\cite{wiki4218}.

%\begin{figure}[t]
%\centering
%\includegraphics[width=3.5in]{images/Visio-comments.pdf}
%\caption{Selected Comments on the Project}
%\label{fig:comments}
%\end{figure}

%\todo{Add more details on how we collected feedback.}

\subsection*{Feedback from Students}
The university collects feedback for all the modules taught through an on-line system. Submitting such feedback gives an incentive to the students in the form of bidding points. These points can be used by students to opt for modules of their preference. This system allows students to provide both quantitative and qualitative feedback. %Further, they can optionally nominate at most 1 teacher for the best teacher award every semester.

Both projects were very well received by the students as indicated by both quantitative and qualitative feedback. Table~\ref{tab:feedback} shows the summary of the quantitative feedback received for the year before and after the introduction of the respective projects in both modules. The average teacher effectiveness score (out of 5.0) increased from 4.037 to 4.242 for EE4214 and from 3.886 to 4.214 for EE4218 in the year following the introduction of the respective projects.
The qualitative feedback received from the students was also quite encouraging. Some selected comments are shown below.
\begin{quotation}
	\textit{``This module provides maximum practical exposure of the concepts learnt. Able to understand the module. The project in this module was time consuming, but gave an in-depth knowledge.''}
\end{quotation}

\begin{quotation}
	\textit{``This module is perfect. It teaches us a lot of stuff about real-time systems and the project is very fun to work on.''}
\end{quotation}

\begin{quotation}
	\textit{``This is a very interesting module because of the project.''}
\end{quotation}

\begin{quotation}
	\textit{``The projects were the best part of this course.''}
\end{quotation}

\begin{quotation}
	\textit{``The module gave good hands-on experience on FPGA implementation.''}
\end{quotation}

\begin{quotation}
	\textit{``We learn a lot about FPGA and VHDL programming.''}
\end{quotation}

\begin{table}[t]
\setlength{\tabcolsep}{6pt}
  \centering
  \caption{Quantitative feedback collected from students}
%    \begin{tabular}{|p{2.5cm}|p{2.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|}
    \begin{tabular}{l | c c | c c}
    \hline
    Module & \multicolumn{2}{c|}{EE4214} & \multicolumn{2}{c}{EE4218}  \\ \hline
    Year & 2009 & 2010 & 2010 & 2011 \\ \hline
    Number of students & 76 & 83 & 93 & 73\\
    Number of respondents & 29 & 39 & 35 & 28 \\
    Percentage of respondents & 38\% & 47\% & 38\% & 38\%\\
    Overall numerical score (out of 5) & 4.037 & 4.242 & 3.886 & 4.214 \\ \hline
\end{tabular}
\label{tab:feedback}
\end{table}

Besides the generic survey conducted by the university, a more specific survey was carried out to obtain students' perception about the use of projects for learning embedded systems. The survey included questions about the practicality of the projects, the difficulty level and the relevance of preparatory labs. It also captured the most motivating/demotivating factors while doing the project. The results are summarized in Table~\ref{tab:survey}. The list of motivating and demotivating factors for the two modules are combined and presented in Figures~\ref{fig:motivating} and \ref{fig:demotivating} respectively. Please note that multiple options could be selected by students. Most students appreciate the flexibility of using FPGAs for design projects. The hardware/software co-design approach of the project was also well-received by the students. The visual output was another strong motivating factor when working on these projects. Long synthesis times and the difficulty in debugging the system were the two biggest demotivating factors.

\begin{table}[t]
\setlength{\tabcolsep}{6pt}
  \centering
  \caption{Project specific survey results}
%    \begin{tabular}{|p{2.5cm}|p{2.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|}
    \begin{tabular}{l | c | c}
    \hline
     & EE4214 & EE4218  \\
    Survey questions & (out of 5) & (out of 5) \\\hline
    Practicality of the project & 3.43 & 3.57 \\
    Difficulty level & 4.36 & 3.48 \\
    Relevance of preparatory labs & 3.71 & 4.05 \\ \hline
\end{tabular}
\label{tab:survey}
\end{table}

\begin{figure}[t]
\centering
\includegraphics[width=1\columnwidth]{images/survey-motivating.pdf}
\caption{List and percentage of motivating factors for the projects}
\label{fig:motivating}
\end{figure}

\begin{figure}[t]
\centering
\includegraphics[width=1\columnwidth]{images/survey-demotivating.pdf}
\caption{List and percentage of demotivating factors for the projects}
\label{fig:demotivating}
\end{figure}

%    Nominations for best teacher & 3 & 7 \\
%    Percentage of nominations & 10\% & 18\% \\

%An example of student comment -- ``This module provides maximum practical exposure of the concepts learnt. Able to understand the module. The project in this module was time consuming, but gave an in-depth knowledge.'' Many other students have given similar comments.

\section{Conclusions and Discussions}
\label{sec:ConclusionsDiscussions}
Teaching embedded systems can be quite challenging since it spans multiple disciplines. Hands-on experiments are essential to convey the many design principles of such systems. In addition, projects are needed to give students a sense of achievement while reinforcing the concepts taught in the class. A real-time embedded systems project and an embedded hardware design project in our university are described here. These projects make use of a generic architecture and expose students to the concepts in embedded systems design while still making it fun for them. Sufficient foundation is provided to ease the learning curve for students.

One of the disadvantages of EE4214 project is that a number of FPGA boards are necessary since the project requires extensive use of hardware. We give 3 FPGA boards to each team so that they can easily build and test the entire system in their group. For large classes, significant initial investment may be needed. However, the same board can be used for multiple courses, e.g. digital fundamentals, microprocessor design and computer architecture.

We have received interests from other universities to adopt our projects/lab material in their relevant courses. We sincerely hope that this description will allow faculty members of other universities to develop projects that allow students to better appreciate the constraints imposed by embedded platforms and gain a good experience in working with them.

\section*{Acknowledgements}
\label{sec:Acknowledgements}
We would like to thank Xilinx University Program for their support. They donated licenses for their ISE Embedded Edition, sponsored the prizes for top three teams and sponsored a trip to Beijing for the top team to participate in open hardware contest~\cite{xilinxopenhw}.
%We would also like to thank Prof Prahlad Vadakkepat for his inputs in how strategies are designed in autonomous robot-soccer systems. Special thanks goes to Mr Rajesh Panicker for his assistance in reviewing drafts of the paper.

%\IEEEtriggeratref{2}
\bibliographystyle{IEEEtran}
\bibliography{ieee-trans-edu}
\end{document}
